-2- Serial No. 09/400,507 

Docket No. ST999034 
Firm No. 0055.0006 

REMARKS 

The Examiner allowed claims 5, 6, 13, 14, 19, 20, and 27. 

The Examiner rejected pending claims 1-4, 7-12, 15-18, and 21-26 as obvious (35 U.S.C. 
§103) over Pirahesh (U.S. Patent No. 5,548,758). Applicants traverse the prior art rejections for 
the following reasons. 

Independent claims 1, 9, and 17 require transforming data in an input table in a database 
in a server in communication with a client by: receiving from the client a transform command 
indicating an input data table name in the database and at least one rule indicating at least one 
cell in the input table to transform and a transform operation to perform with respect to the at 
least one cell; accessing a copy of the input table from the database; and transforming, within the 
server, data in the accessed input table according to each rule specified in the transform 
command. 

First off, Applicants note that Pirahesh generally does not concern transforming data in an 
input table according to rules as claimed. Instead, Pirahesh concerns how to optimize an SQL 
query, not transfer data in an input data table in a database. Applicants submit that optimizing an 
SQL query is a different type of operation than transforming data in an input table as claimed. 

The Examiner cited col. 3, lines 29-38 as teaching the claim requirement of transforming, 
within the server, data in the accessed input table according to each rule specified in the 
transform command. (Third Office Action, pg. 3). Applicants traverse. 

The cited col. 3 discusses the steps for execution of SQL statements. An application plan 
for the compiled SQL statements is generated which concern how to get the data the user wants. 
The cited col. 3 discusses how generating the access plan considers available access paths, such 
as indexes, sequential reads, etc., and system statistics on the data to access to choose the most 
efficient access path. 

Nowhere does this cited col. 3 anywhere teach or suggest the claim requirement of 
transforming data in the accessed input table according to each rule specified in the transform 
command. Instead, the cited col. 3 concerns how to develop an application plan to execute an 
SQL query, not how to transform cells in an accessed input table according to rules specified in a 
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transform command. Nowhere does the cited col. 3 anywhere mention transform commands 
having rules to transform data in an input table. Instead, the cited col. 3 concerns something 
entirely different, how to optimize the execution of an SQL command. 

The Examiner cited the "where clause" discussed in col. 4, lines 38-60 of Pirahesh as 
rendering obvious the claim requirement of receiving from the client a transform command 
indicating an input data table name in the database and at least one rule indicating at least one 
cell in the input table to transform and a transform operation to perform with respect to the at 
least one cell. The Examiner found that the "where clause" renders obvious this claim 
requirement because the "where clause" contains a search condition that must be satisfied by 
each row in the result table to form an intermediate set that is further processed according to the 
select clause. (Office Action, pg. 3) Applicants traverse. 

The cited col. 4 discusses a WHERE clauses that determines which rows should be 
returned and a SELECT statement that provides yet further predicates to use to select rows from 
a table to return. Pirahesh notes that the SELECT statement determines the columns that will be 
returned from the table identified in the FROM clause. (Pirahesh, col. 4, lines 20-26). 

The cited col. 4 concerns an SQL statement to return specific data from rows of a table. 
Nowhere does this cited section anywhere teach or suggest a transform command indicating cells 
in an input table and a transform command to transform data in the input table according to the 
transform operation. Instead, the cited col. 4 discusses rules used to query a table to return data 
from that table. Nowhere does the cited col. 4 anywhere suggest transform operations to actually 
transform data in the input table. 

The Application defines the term "transformation" as the process of filtering, merging, 
decoding, and translating source data to create validated data, such as converting data, applying 
mathematical or logical operators on the values of data, etc. (Application, col. 2, lines 13-26) 
Nowhere does the cited col. 4 anywhere teach or suggest a transform command indicating a 
transform operation to transform data in the input table indicated in the command. Instead, the 
cited col. 4 only concerns how to query and return data that satisfies conditions specified in the 
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query WHERE and SELECT statements, no transformation of data, as that term is defined in the 
Application, is suggested. 

The Examiner further cited the join operation discussed on col. 4, lines 52-60 of Pirahesh. 
(Third Office Action, pgs. 3-4) The cited col. 4 notes that a join operation involves 
concatenating rows from different tables. Applicants submit that the cited join operation is 
different and does not teach or suggest the claimed transform operation which comprises altering 
data in cells in an input table. A join operation does not transform data in cells in an input table, 
but instead concatenates rows of data from multiple tables to perform a search with respect to the 
joined rows. 

Moreover, the claims require that the received transform command indicate at least one 
cell in the input table to transform and a transform operation to perform with respect to such cell. 
The cited join operation does not indicate at least one cell in an input table to transform 
according to an indicated transform operation. Instead, a join operation concerns concatenating 
rows of a table, not performing transformations on cells in an input table. 

Accordingly, claims 1, 9, and 17 are patentable over the cited Pirahesh because the cited 
Pirahesh does not teach or suggest all the requirements of these claims. 

Claims 2-4, 7, and 8; 10-16, and 18-21 and 26 are patentable over the cited art because 
they depend from claims 1, 9, and 17, respectively, which are patentable over the cited art for the 
reasons discussed above. Moreover, claims 2, 4, 7, 8, 10, 12, 15, 16, 18, 21, 22, and 26 provide 
additional ground of patentability over the cited art. 

Claims 2, 10, and 26 depend from claims 1, 9, and 17 , respectively, and further require 
that the client is a client computer that communicates with the server over a network, wherein the 
transform command is transmitted from the client computer to the server over the network. The 
Examiner cited col. 1, lines 12-13 of Pirahesh as teaching the additional requirements of these 
claims. (Third Office Action, pg. 4) Applicants traverse. 

The cited col. 1 mentions database systems performed by computers and the optimization 
of queries. Nowhere does this cited col. 1 anywhere teach or suggest the claim requirement that a 
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client computer transmits a transform command as claimed to a server over the network to 
transform data within the server as claimed. 

, Accordingly, claims 2, 10, and 26 provide additional grounds of patentability over the 
cited art. 

Claims 4, 12, and 18 depend from claims 1, 9, and 17 and further require that the 
transform command rules specify multiple transform operations to perform on at least one cell in 
the accessed input table. An application of a subsequent transform operation following a 
previous transform operation on one cell transforms previously transformed data in the cell. 
The Examiner cited col. 6, lines 21-26 of Pirahesh as teaching the additional requirements of 
these claims. (Third Office Action, pg. 5) Applicants traverse. 

The cited col. 6 mentions an early-out join where each row in the outer table is joined 
with at most one row in the inner table so that less rows need to be joined. Nowhere does this 
cited col. 6 anywhere teach or suggest the claim requirement of rules specifying multiple 
transform operations on cells in an accessed input table to transform the data, as the term 
transform is understood. Instead, the cited col. 6 only concerns a join operation which concerns 
concatenating rows from different tables, not transforming cells in an input table as claimed. 
Again, Applicants submit that joining rows from different tables does not teach or suggest 
transforming cells in an input table as claimed. 

Accordingly, claims 4, 12, and 19 provide additional grounds of patentability over the 
cited art. 

Claims 7, 15, and 26 depend from claims 1, 9, and 17 and further require that the client 
cannot affect the execution of the transform command during the execution of the transform 
command, whereby the transform command executes in the server independently of the client. 
The Examiner cited col. 9, lines 7-15 of Pirahesh as teaching the additional requirements of 
claims 7 and 15. (Office Action, pg. 5) Applicants traverse. 

The cited col. 9 discusses how to perform an inner join operation. Nowhere does the 
cited col. 9 anywhere suggest that a client cannot affect the execution of the transform command 
so that the command executes independently of the client that provided the transform command 
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to the server. The Examiner appears to take the position that because the cited join process is a 
self contained operation, a client cannot affect'the execution of the operation. (Third Office 
Action, pg. 5) Applicants submit that this cited section still nowhere suggests the claim 
requirement that a client cannot affect the execution of the transform command the client 
transmitted to the server. The fact that the cited col. 9 discusses a self-executing join operation 
does not suggest that a client could not interrupt or affect the execution of this join operation. 

Accordingly, claims 7, 15, and 26 provide additional grounds of patentability over the 
cited art. 

Claims 8, 16, and 21 depend from claims 1, 9, and 17 and further require that the 
transform command comprises multiple rules, wherein each rule specifies at least one column in 
the input table and at least one transform operation to perform on each specified column in the 
input table. At least two rules specify different columns in the input table and different transform 
operations to apply to each specified column. The Examiner cited page col. 9, lines 31-40 of 
Pirahesh as teaching the additional requirements of claims 8, 16, and 21 . (Office Action, pgs. 5- 
6) Applicants traverse. 

The cited col. 9 discusses steps to perform a join operation. When the join is executed, a 
check is made to see if the join is an early-out join. If so, the one match from the inner table is 
output for each row of the outer table in the join. Again, the cited col. 9, like other sections of 
Pirahesh, just discusses how to join rows from different table. Nowhere does the cited col. 9 
anywhere teach or suggest a transform command having multiple rules, where each rule specifies 
one column at one transform operation to perform on each specified column, where at least two 
rules specify different columns in the input table. Instead, the cited col. 9 concerns performing a 
join operation, which involves concatenating rows from different tables, not the claim 
requirements of transforming data in different columns in an input table according to rules in a 
transform command. 

For these reasons, claims 8, 16, and 21 provide additional grounds of patentability over 
the cited art. 
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Claims 22-25 include many of the distinguishing requirements found in claims 1, 4, 6, 
and 8 in data structure format, and are patentable over the cited art for the reasons discussed with 
respect to claims 1, 4, and 6. 



Conclusion 

For all the above reasons, Applicant submit that all the pending claims 1-27 are 
patentable over the art of record. Applicants submit that no fee is needed. Nonetheless, should 
any additional fees be required, please charge Deposit Account No. 50-0585. 



The attorney of record invites the Examiner to contact him at (310) 553-7977 if the 
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